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Abstract 



This paper formalizes a small object-oriented programming notation. The no- 
tation features imperative commands where objects can be shared (aliased), and is 
rich enough to allow subtypes and recursive object types. The syntax, type check- 
ing rules, axiomatic semantics, and operational semantics of the notation are given. 
A soundness theorem showing the consistency between the axiomatic and opera- 
tional semantics is stated and proved. A simple corollary of the soundness theorem 
demonstrates the soundness of the type system. Because of the way types, fields, 
and methods are declared, no extra effort is required to handle recursive object 
types. 
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0 Introduction 

It is well known that C.A.R. Hoare's logic of the basic commands of imperative, pro- 
cedural languages [8] has been useful in understanding imperative languages. Object- 
oriented programming languages being all the rage, one is surprised that the literature 
has not produced a corresponding logic for modern object-oriented programs. The con- 
trol structures of object-oriented programs are similar to those treated by Hoare, but 
the data structures of object-oriented programs are more complicated, mainly because 
objects are (possibly shared) references to data fields. 

This paper presents a logic for an object-oriented programming notation. In an early 
attempt at such a logic, Leavens gave an axiomatic semantics for an object-oriented 
language [10]. However, the language he used differs from popular object-oriented lan- 
guages in that it is functional rather than imperative, so the values of the fields of objects 
cannot be changed. America and de Boer have given a logic for the parallel language 
POOL [3]. This logic applies to imperative programs with object sharing (sometimes 
called aliasing), but without subtyping and method overriding. In a logic that I will refer 
to as logic AL, Abadi and I defined an axiomatic semantics for an imperative, object- 
oriented language with object sharing [1], but it does not permit recursive object types. 
Poetzsch-Heffter and Miiller have defined (but not proved sound) a Hoare- style logic for 
object-oriented programs that remove many of the previous limitations [16]. However, 
instead of following the standard methodological discipline of letting the designer of a 
method define its specification and then checking that implementations meet the specifi- 
cation, the specification of a method in the Poetzsch-Heffter and Miiller logic is derived 
from the method's known implementations. The present logic deals with imperative 
features, subtyping, and recursive object types. 

The literature has paid much attention to the type systems of object-oriented lan- 
guages. Such papers tend to define some notion of types, the commands of some lan- 
guage, the type rules and operational semantics for the commands, and a soundness 
theorem linking the type system with the operational semantics. (Several examples of 
this are found in Abadi and Cardelli's book on objects [0].) But after all that effort, 
one still doesn't know how to reason about the programs that can be written with the 
provided commands, since no axiomatic semantics is given. In addition to giving a pro- 
gramming notation and its axiomatic semantics, this paper, like the paper describing 
logic AL, gives an operational semantics and a soundness theorem that links the opera- 
tional semantics with the axiomatic semantics. The soundness theorem directly implies 
the soundness of the type system. 

A complication with type systems is that types can be recursive, that is, an object 
type T may contain a field of type T or a method whose return type is T . The literature 
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commonly treats recursive data types by introducing some sort of fix-point operator 
into the type system, good examples of which are a paper by Amadio and Cardelli on 
recursive types and subtypes [2] and the book by Abadi and Cardelli. By treating types 
in a dramatically different way, the present logic supports recursive object types without 
the need for any special mechanism like fix-points. The inclusion of recursive object 
types is one main advantage of the present logic over logic AL, which does not allow 
them. (The other main advantage over logic AL is that the present logic can be used with 
any first-order theory.) Because the given soundness theorem implies the soundness of 
the type system, the present work contributes also to the world of type systems. 

In difference to the paper by Amadio and Cardelli, which considers unrestricted 
recursive types, the type system in the present paper uses a restriction along the lines 
of name matching. In particular, types are simply identifiers, and the subtype relation 
is simply a given partial order among those identifiers. This is much like the classes 
in Java [7] or the branded object types in Modula-3 [15]. But in contrast to languages 
like Java or Modula-3, fields and methods are declared separately from types in the 
language considered in this paper. (This is also done in Cecil [4] and Ecstatic [12].) Not 
only does this simplify the treatment without loss of applicability to languages like Java 
and Modula-3, but it also makes explicit the separation of concerns. For example, as the 
logic shows, having to know all the fields of a particular object type is necessary only 
for the allocation of a new object. 

Furthermore, when a field or method is declared for some type T , each subtype 
of T automatically acquires, or inherits, that field or method. Consequently, one gets 
behavioral subtyping for free, something that can also be achieved by the inheritance dis- 
cipline considered by Dhara and Leavens [5]. In contrast, subtype relations frequently 
found in the literature (including the subtype relation used in logic AL), involves the 
fields and methods of types. In such treatments of types, one often encounters words 
like "co- variant"; there will be no further occurrence of such words in this paper. 

The rest of this paper is organized as follows. Section 1 relates the present logic to 
some work that has influenced it. Section 2 describes the declarations that can be used in 
program environments, and Section 3 describes the commands: their syntax, axiomatic 
semantics, and operational semantics. Section 4 discusses an example program. Then, 
Section 5 states the soundness theorem, whose proof is given in the appendix. Section 6 
discusses some limitations of the logic, and the paper concludes with a brief summary. 
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1 Sources of influence 

My work with Abadi has inculcated the present logic with its style and machinery. The 
present logic also draws from other sources with which I am quite familiar: my the- 
sis [11], my work on an object logic with Nelson [13], and the Ecstatic language [12]. 
This section compares the features of these sources of influence with the features of the 
present logic. 

My thesis includes a translation of common object-oriented language constructs into 
Dijkstra's guarded commands, an imperative language whose well-known axiomatic se- 
mantics is given in terms of weakest preconditions [6]. My attempt at an object logic 
with Nelson is also based on guarded commands, and Ecstatic is a richer object-oriented 
programming language defined directly in terms of weakest preconditions. Types, fields, 
and methods in these three sources are declared in roughly the same way as in the present 
logic. While these sources do provide a way to reason about object-oriented programs, 
they take for granted the existence of an operational semantics that implements the ax- 
iomatic semantics. The present paper includes an operational semantics for the given 
commands, and establishes the correctness of the operational semantics with respect to 
the axiomatic semantics by proving a soundness theorem. 

Like logic AL, the present logic has few and simple commands. Each command in 
logic AL operates on an object store and produces a value placed in a special register 
called r . In the present logic, commands are allowed to refer to the initial value of 
that register, which simplifies many of the rules. (It also makes the commands "cute".) 
Another difference is that the present logic splits logic ALs let command into two 
commands: sequential composition and binding. The separation works well because 
the initial value of register r can be used. Perhaps surprisingly, another consequence 
of using the initial value of r is that the present logic manages fine without Abadi and 
Cardelli's g binder that appears in logic AL to bind a method's self parameter. 

2 Environments 

This section starts defining the logic by describing program environments and the dec- 
larations that a program environment can contain. 

A program environment is a list of declarations. A declaration introduces a type, a 
field, or a method. 

An identifier is said to be declared in an environment if it is introduced by a type, 
field, or method declaration in the environment, or if it is one of the built-in types. I 
write x g E to denote that identifier x is not declared in environment E . 
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The judgement E h o says that £ is a well-formed environment. The empty list, 
written 0 , is a valid environment. 

Empty environment 

The next three subsections describe types, fields, and methods, and give the remaining 
rules for well-formed environments. 



A type is an identifier. There are two built-in types, Boolean and Object . (Other types, 
like integers, can easily be added, but I omit them for brevity.) Types other than Boolean 
are called object types. A new object type is introduced by a subtyping pair, which has 
the form T<:U , where T is identifier that names the new type, and U is an object 
type. Like in Java, Object denotes the root of the class hierarchy. The analogue of a 
subtyping pair T<:U in Java is a class T declared as a subclass of a class U : 

class T extends U { . . . } 

A type is said to be declared in an environment if it is Boolean , Object , or if it oc- 
curs as the first component of a subtyping pair. To express this formally, the judgement 
E \~type T says that T is a type in environment E , and the judgement E \- ob j T says 
that T is an object type in E . The rules for these judgements are as follows. Here and 
throughout this paper, I use T and U , possibly subscripted, to denote types. 

Types in environments 



2.0 Types 



Eh ohj U T?E 
(E,T<:U)ho 



Declared types (h^, h ohj ) 



Eho 



(E, T<:U,E') h o 



E \- obj Object 



(E,T<:U,E>) h obj T 



E\~. 



type 



EhO 



Boolean 




The reflexive, transitive closure of the subtyping pairs forms a partial order called 
the subtyping order. The judgement E h T <: U says that T and U are types in E 
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that are ordered by the subtyping order. Type T is then said to be a subtype of U . The 
rules are: 

Subtyping order (h <:) 

E Vjype T (E,T<:U,E')ho E h T Q <: T, E h T, <: T 2 

EhT<:T (E,T<:U,E')h T <: U E h T 0 <: T 2 

2.1 Fields 

A field is a map from an object type to another type. A field f is introduced by afield 
triple, written f : T —> U , where f is the identifier that names the field, T is an object 
type called the index type of f , and U is a type called the range type of f . The analogue 
of a field triple f : T -> U in Java is an instance variable f of type U declared in a class 
T : 

class T { ... U\\ . . . } 

An environment can contain field triples. A field f is said to be declared in an 
environment E if it occurs in some field triple f : T —> U in E . This is expressed by 
the judgement E \-fieu f ; T U . The rules for these judgements are as follows. Here 
and throughout, I use f , possibly subscripted, to denote field names. 

Fields in environments 

E \- obj T E \jype U f_g_E 
(E, f: T U) h o 

Declared fields ( \- fie i d ) 

(E, f: T -> U, E') h o 

(E, tTTTj, W) h field JPFTu 

For a type T 0 declared in an environment E , the set of fields of T 0 in E , written 
Fields(T 0 , E) , is the set of all field triples i:T -> U such that E \-fi M t:T -> U and 
EhT 0 <:T. 

2.2 Methods 

A method quadruple has the form m: T -> U : R , where m is an identifier denoting a 
method, T is an object type, U is a type, and R is a relation. The analogue of a method 
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quadruple m: T -> U : R in Java is a method m with return type U declared in a class 
T and given a specification R : 

class T{ ... Um() {...}... } 

Note that the Java language does not have a place to write down the specification of a 
method. In the present language, the declaration of a method includes a specification, 
which specifies the effect of the method as a relation on the pre- and post-state of each 
method invocation. Note also that methods take no parameters (other than the object 
on which the method is invoked, an object commonly referred to as self). This simpli- 
fies the logic without losing theoretical expressiveness, since parameters can be passed 
through fields. 

An environment can contain method quadruples. A method m is said to be declared 
in an environment E if it occurs in some method quadruple m: T —> U : R in E . This 
is expressed by the judgement E \- method m: T -> U : R. Formally, the rules are as 
follows. I use m , possibly subscripted, to denote methods. 

Methods in environments 

E h ohj T E Vjype U E,0\- nl R m<?E 
(E, m: T -> U : R) h o 

Declared methods ( \- met hod ) 

(E,m:T -> U : R, E') h o 
(E,m:T^U: R, W) h method m:T ^ U : R 

The judgement E, 0 \- re i R, which will be described in more detail in Section 3.1, 
essentially says that R is a relation that may mention fields declared in E but doesn't 
mention any local program variables. 

For a type Tq declared in an environment E , the set of methods of Tq in E , written 
Methods (To, E) , is the set of all method quadruples m: T -> U : R such that E \- method 
m:T -> U :R and E h T 0 <: T. 

2.3 Relations 

Methods are specified using relations. A relation is an untyped first-order predicate on 
a pre-state and a post-state. In order to make relations expressive, the present logic can 
be used with an underlying logic, which provides a set of function symbols and a set of 
first-order axioms about those function symbols. The example in Section 4 shows how 
an underlying logic may be used. 

Syntactically, relations are made up only of: 
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• the constants false , true , and nil ; 

• constants for field names, and the special field alloc ; 

• the special variables r , f , a , a ; 

• other variables (I will write v to denote a typical variable); 

• equality between terms; 

• applications of the functions select and store ; 

• applications of the functions of the underlying logic; 

• the usual logical connectives -< , A , and V . 

The grammars for relations (R ) and terms ( e ) are thus: 

R :;= eQ = ei \ -,r \ r q a r { \ (y* :: R } 

e ::= false | true | nil | f 

! r | f | o | a | v 

| select(e 0 , e\, e 2 ) \ store(e 0 , e\, e 2 , e 3 ) 

| pa(e 0 , • • • , Cfa-i) I ••• | pz(e 0 , • • • , Cfe_i) 

where pa,...,pz denote the function symbols of the underlying logic with arities 
ka, ... ,kz, respectively. It will be convenient to also allow ^ , V , =>• , •<= , 
= , and 3 as the usual abbreviations of the operators above. 
The semantics of a command (program statement) is defined in terms of a relation 
on a register and a. (data) store, together called a state. The variables r and f denote the 
register in the pre- and post-states of the command, respectively, and a and a denote 
the store in those respective states. The value of a field f of an object e in a store 
o is denoted select(cr, e, f) . The expression store(a, e 0 , f, e\) represents the store that 
results from setting the f field of object e 0 in store a to the value e\ . The relationship 
between select and store is defined as follows. 

(V<7,e 0 ,ei,fo,fi,e :: 

select(store(a, e 0 , fo, <?), e 0 , fo) = e A 
Oo # ei V f 0 # fi => 

select (store (a, eo, fo, e), ei, fi) = select (a, e\, \\)) ) 

The special field alloc is used to record which objects in the data store have been 
allocated; the alloc field of an object is false until the object is allocated, and is true 
from there on. 
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As we shall see, the logic allows relations to be rewritten. A rewriting uses the rules 
of logic and some axioms. In particular, a rewriting may use as axioms the definition of 
select and store (0), the distinctness of the boolean values: 

false ^ true , (1) 
the distinctness of field name constants: 

all field name constants (including alloc) are distinct , (2) 
and the axioms of the underlying logic. 



3 Commands 

This section describes commands: their syntax, their axiomatic semantics, and their 
operational semantics. 

3.0 Syntax 

A command has a form dictated by the following grammar. 

a ::= c constant 

| v local variable 

| a 0 o a i conditional 

| a 0 ; a\ composition 

| with v:T do a binding 

| [T: t{ = Ci ,eI , m, = Oj jeJ ] object construction 

| f field selection 

| f := v field update 

| m method invocation 

c ::= false | true | nil 

Informally, the semantics of the language is as follows. (Recall from the previous 
section that commands operate on a register and a store.) 

• The constants false , true , and nil evaluate to themselves. That is, they have the 
effect of setting the register to themselves. 

• A local variable is an identifier introduced via a binding command. Every local 
variable is immutable: once bound (using with , see below), the value of a local 
variable cannot be changed. A local variable evaluates to its value. 
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• The conditional command evaluates ao if the register is initially false , and eval- 
uates a i if the register is initially true . Note that the guard of the conditional 
is not shown explicitly in the command; rather, the initial value of the register is 
used as the guard. 

• The sequential composition of ao and a\ first evaluates ao and then evaluates a\ . 
The final values of the register and store in the evaluation of ao are used as the 
initial values of the register and store in the evaluation of a\ . Composition is usu- 
ally written a 0 ; a\ , but to keep the language looking like popular object-oriented 
languages, I also allow the alternative syntax ao ■ a\ (see examples below). 

• The binding command with v:T do a introduces a local variable v for use in a . 
Its evaluation consists in evaluating a with v bound to the initial value of the 
register. 

• The command [T: f, = c, ,6/ , m, = Oj jeJ ] constructs a new object of type T , 
and sets the register to (a reference to the fields and methods of) the object. The 
command must list every field f, from the set of fields of T . The initial value 
for field f, is the given constant c, . The command must also list every method 
m, from the set of methods of T . The implementation of method m, for the new 
object is given as the command aj , which receives self as the initial value of the 
register and returns the method result value as the final value of the register. The 
command aj cannot reference local variables other than those it declares. 

• A field can be selected (f) and updated (f := v). Both operate on the object 
referenced by the initial value of the register. Selection sets the register to the f 
field of the object. Update sets the f field of the object to the value of v , leaving 
the register unchanged. 

• The method invocation m finds the implementation of method m for the ob- 
ject referenced by the initial value of the register, and then proceeds to evaluate 
that implementation. The evaluation of the implementation begins with the initial 
register and store values of the invocation, and the invocation ends with the final 
register and store values of the evaluation of the implementation. Other than the 
initial and final register values (which encode self and the result value, respec- 
tively), a method does not have explicit parameters; instead, parameters can be 
passed via the fields of the object. 

Here are some examples that compare the present commands with programs written 
in other languages. The Modula-3 program statement if b then S else T end is written 
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as the command 
b; (ToS) 

The Modula-3 expression new(T, f := true) A , where T is an object type with one field 
f and no methods, is written as the command 

[T : f = true] ; f 

or with the alternative syntax for composition, the command is written 

[T : f = true\.\ 
The Modula-3 program x\ := true is written 

true ; with v: Boolean do x.\ := v 
As an example of object sharing, the command 

[T: f = c] ; with v: T do with w: T do (v.f := y ; w.\) 

allocates a new T object whose f field is set to c , creates two references to the object 
( v and w ), updates the object's f field via v , and reads f back via w , returning y . 

The following example shows the construction of a T object whose method or 
computes the disjunction of fields x and y : 

[T: x = false, y = false, or = with self: T do (x ; (self.y o true))] 

Note that although primitive, the programming notation is expressive enough to ad- 
mit common object-oriented languages features like object construction, method invoca- 
tion, and object sharing. The programming notation is kept minimal in order to simplify 
the associated rules. 

3.1 Axiomatic semantics 

This subsection gives the axiomatic semantics of the commands. The judgement 

E, Vha:T^ U:R 

says that command a in command environment (E, V) can be started in a state where 
the register contents has type T , and terminates in a state where the register contents 
has type U . The execution of a is such that its pre- and post-states satisfy the relation 
R . The rules of the axiomatic semantics double as type checking rules, because with a 
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trivial R (such as r = r ), the judgement expresses what it means for command a to be 
well-typed. 

Before giving the axiomatic semantics, some other definitions and rules pertaining 
to constants, local variables, and command environments are in order. 

There are three constants: false , true , and nil . The judgement E \- const c: T ex- 
presses that constant c has type T . 

Type of constants ( \- const ) 

Eho Eho E\- ohj T 

E h const false: Boolean E \- con st true: Boolean E \- const nil: T 

A local variable declaration has the form v: T , where v is an identifier denoting a 
local variable and T is a type. A command environment is a pair (E, V) , where E is 
a program environment and V is a list of local variable declarations. A local variable 
v is said to be declared in a command environment (E, V) if it occurs in some local 
variable declaration v:T in V . This is expressed by the judgement E, V \- var v: T . 
Thus, in a command environment (E, V) , E contains declarations of types, fields, and 
methods, whereas V contains declarations of local variables. This separation allows a 
simple characterization of a command environment without local variable declarations: 
(E, 0) . We saw this in the "Methods in environments" rule in Section 2.2, and we will 
see it in the "Object construction" rule below and in Theorems 0, 1, and 2 in Section 5. 

The judgement 

E, V \- rel R 

says that R is a relation whose free variables are fields or local variables declared in 
(E, V) , or are among the special fields and variables alloc , r, f, b , and a . The 
obvious formal rules for this judgement are omitted. Thus, the judgement E, 0 \- ret R 
used in the hypothesis of the "Methods in environments" rule in Section 2.2 implies that 
R does not mention local variables. 

I write x $ (E, V) to denote that identifier x is not declared in command environ- 
ment (E, V) . The formal rules of the above are then: 

Well-formed command environment 

Eho E,Vho v#(E,V) Ehty, pe T 
E,0ho E, (V, v:T)ho 

Declared local variables ( \- var ) 
E, (V, v: T, V) h o 
E, (V, v: T, V) h var v: T 
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Now for the rules of the axiomatic semantics. There is one rule for each command, 
and one sub sumption rule. 

Subsumption 

E, V h a : 7i -> T 2 : 
E\-T 0 <:T { EhT 2 <: T 3 h /o , g =» # E, y h rg< g 

E,Vha:T 0 ^T 3 :R> 

The judgement hyy P represents provability in first-order logic, under axioms (0), (1), 
and (2) from Section 2.3 and the axioms of the underlying logic. 

Constant 

E,V \- o E \- const c:T E U 
E,V h c : C/ -> r : f = c A a = a 

Local variable 

E,Vhv:U^T:r = v Aa =6 
Conditional 

E, V h ao : Boolean T : Ro 
E, V h fli : Boolean T : R[ 

E, V h «o o «i : Boolean — > 7 1 : (r = false =>• i?o) A (r = ?rwe =>• 
Composition 

£, V h a 0 : r 0 -> 7i : tf 0 
£, V h ai : 7i -> T 2 : /? x 
r and a do not occur free in i? 0 or 7?i 

£, y h a 0 ; ai : T 0 -> T 2 : (3r, a :: i? 0 l/, ^ := r, a] A i?i[r, a := f, a] } 
Binding 

£, (y, v: r) h a : T -> [/ : i? 
£, y h with v:T doa:T ^ U : R[v:=r] 
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Object construction 

E,Vho E U E h ohj T 

f ; : T { -> Ui !6/ are the elements of Fields(T, E) 

m,: Tj -> Uj : Rj jeJ axe the elements of Methods(T, E) 

E \~const_ cf. Ui ieI E,0h aj :T^ Uj: g & 

E,Vh [T: f, = a ieI , m, = aj jeJ ] : U -> T : 
r ^ nil A select(cr, f, alloc) = false A 
6 = store(- ■ ■ (store (a , f, alloc, true), f, f,, c ; ) ,6/ 

Field selection 

E,Vho E \- fie i d f: T -> U 
E, V h f : T —> U : r y£ nil =>• f = selectip , r, f ) A a = a 

Field update 

E h fidd f: T 0 -> C/ 0 £ h <: T 0 

£, V K, a ,. v: tA EhU { <:U 0 

is, V h f := v : T\ — > 7\ : r 7^ ni7 =>• r = r A a = store(cr, r, f, v) 

Method invocation 

E,Vho E h method m:T^U:R 
E,Vhm:T^U:r^nil^R 

3.2 Operational semantics 

The operational semantics is defined by the judgement 

r, a, /x, S h a ~> r', cr', /x' 

It says that given an initial operational state (r, cr, /x) and stacfc S , executing command 
a terminates in operational state (r 1 ', cr' , /x') . Operational states are triples whose first 
two components correspond to the register and data store components of states, as de- 
fined above. The third component is a method store. To define stacks and method stores, 
I first give some definitions. 

For a partial function / from A to B , a e A , and b e B , I write f.(a i-> to 
denote the function that is like / except possibly at a , which it maps to b . A function 
/' is called an extension of a function / , written / < /' , if domif) C domif') and, for 



13 



every a G domif) , f(a) = f'(a) . When a t G A ,6/ are distinct and & ; g B ,6/ , I write 
(cii i-> ,6/ ) for the partial function from A to 5 that maps a, to Z?; for i G / and is 
otherwise undefined. The partial function whose domain is empty is written 0 . 

Let V, denote a set of given object names. I assume V, f) {false, true, nil} = 0 . A 
stack is a partial function from local variables to V, U {/a/s<?, Jrwe, ra7} . A method store 
is a partial function /x from V, , such that 

• /z(/z) (type) is the allocated type of object h , and 

• /z(/z)(m) , if defined, is the implementation of method m of object h . 

A store pair is a pair (cr, jx) where a is a data store and jx is a method store. 

In addition to keeping the method implementations of objects, the method store 
keeps the allocated type of objects. The operational semantics records this informa- 
tion as it allocates a new object, but doesn't use it subsequently. The information is used 
only to state and prove the soundness theorem. By conveniently recording this informa- 
tion in the operational semantics, where it causes no harm, one avoids the use of a store 
type (cf. [1]). The result is a simpler statement and proof of soundness. 

The rest of this subsection gives the rules of the operational semantics. 

Constant 



r, cr, /x, S h c ~> c, o, /x 

Local variable 

r 7 = S(v) 
r, a, [i, S h v ~> r' , a, \x 

Conditional 

false, a, fx, S h ao ~> r\ a' , /x' true, a, /x, S h ai ~> r', a', /x' 

/a/se, a, /x, 5 h ao o «i r\ cr', /x' ?rwe, cr, /x, S h ao o «i ~> r\ a', /x' 

Composition 

r, a, /x, 5 h ao ~> r\ cr', /x' a', /x', 5 h ai ~> r", a", /x" 

r, o, /X, S h ao ; «i ~> r", cr", /x" 

Binding 

r, cr, /x, S.(v h-> r) h a ~> r 7 , cr', /x' 
r, cr, /x, 5 h with v.T do a f , a', fx' 
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Object construction 

h G V, select(cr, h, alloc) = false 

a' = store(- ■ ■ (store(a, h, alloc, true), h, f,, c,) ,6/ 

/x' = ix. (h h> (type h» r, m, h» ^•■ /e7 )) 

r, a, /x, 5 h [7: f,- = q m, = Oj^ J ] ~> fc, a', /x' 

Field selection 

r € V, r 1 = select(cr, r, f) 
r, cr, /x, 5 h f ~> r', cr, /x 

Field update 

r £ K a' = store(a, r, f, 5(v)) 
r, cr, /x, 5 h f := v ~> r, a' , \x 

Method invocation 

r € V, a = /x(r)(m) r, cr, /x, 0 h a ~> cr', /x' 
r, cr, /x, 5 h m ~> r 7 , cr', /x' 

4 Example 

In this section, I show an example of a program that can be proved in the logic. 

Let us consider a linked-list type with a method that appends a list to another. Rea- 
soning about a program with such a type requires reasoning about reachability among 
linked-list nodes. To this end, we assume the underlying logic to contain a function 
symbol Reach (adapted from Greg Nelson's reachability predicate [14]). Informally, 

Reach(eo, e\, cr, f, e 2 ) 

is true whenever it is possible to reach from object e 0 to object e\ via applications of 
f in cr , never going through object e 2 • 

The example in this section assumes that the underlying logic contains the following 
two axioms, which relate Reach to select and store , respectively. 

(Ve 0 , e\, a, f, e 2 :: 

Reach(eo, e\, cr, f, e 2 ) = true = (3) 
eo = e\ v (e 0 ^ e 2 A Reach(select(a, eo, f), e\, cr, f, e 2 ) = true) ) 
( Ve 0 , e\, cr, f 0 , e 2 , fi, e 3 , e A :: f 0 # fi =>■ ... 
Reach(eo, e\, cr, fo, e 2 ) = Reach (eo, e\, store(a, e 3 , fi, £4), fo, e 2 ) ) 
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Axiom (3) resembles Nelson's axiom Al and says that every object reaches itself, and 
that eo reaches e\ if eo is not and e§.\ reaches e\ . Axiom (4) says that whether or 
not eo reaches e\ via fo is independent of the values of another field fi . 
The example uses the following environment, which I shall refer to as E : 

Node<:Object 
next: Node -> Node 
appendArg: Node -> Node 
append: Node -> Node : R 

where R is the relation 

r ^ nil =>• Reach(r, f, a, next, nil) A select{a , f, next) = nil A 
select(&, f, next) = s elect (a , r, appendArg) a 
(Vo,f :: select(a ,o,f) = select(6, o, f) V 

(o = r a f = next) v f = appendArg ) 

Informally, this relation specifies that the method store its argument (which is passed in 
via the appendArg field) at the end of the list linked via field next . More precisely, 
the relation specifies that the method find an object f reachable from r (self) via the 
next field such that f.next is nil. The method is to set f.next to the given argument 
node. The method can modify f.next and can modify the appendArg field of any 
object (since this field is used only as a way to pass a parameter to append anyway), 
but it is not allowed to modify the store in any other way. 

To present the example code, I introduce a new command, isnil , which tests whether 
or not the register is nil . 

Nil test 

E,Vho E h ohj T 

E, V h isnil : T — > Boolean : 

(r = nil =4> r = true) A (r^ nil =4> r = false) A a = 6 

(Section 6 discusses expression commands such as nil tests.) 

To write the program text, I assume the following binding powers, from highest to 
lowest. 

:= . ; o with ... do . 
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Now, consider the following command. 

[Node: next = nil, appendArg = nil, 

append = with self: Node do appendArg ; with n: Node do 
self .next ; isnil ; 

( seZ/.next.appendArg := n ; append (5) 

o self .next := n ; self 

) 

] 

This command allocates and returns a Node object whose next and appendArg fields 
are initially nil . The implementation of append starts by giving names to the self 
object and the method's argument. Then it either calls append recursively on self .next 
or sets self .next to the given argument, depending on whether or not self .next is nil. 

With axioms (3) and (4) in the underlying logic, one can prove the following judge- 
ment about the given allocation command. 

£,0h (5) : Object -> Node :r = r (6) 

Though the relation in this judgement ( r = r ) is trivial, establishing the judgement 
requires showing that the given implementation of append satisfies its declared speci- 
fication. I omit the proof, which is straightforward. 

I conclude the example with three remarks. First, remember that to reason about a 
call to a method, in particular the recursive call to append , one uses the specification 
of the method being called, not its implementation. This makes the reasoning indepen- 
dent of the actual implementation of the callee, which may in fact even be a different 
implementation than the one shown. 

Second, remember that only partial correctness is proved. That is, judgement (6) 
says that if the method terminates, its pre- and post-states will satisfy the specified 
relation. Indeed, an invocation of method append on an object in a cyclic structure of 
Node objects will not terminate. 

Third, the static type of the field self .next and the argument self. appendArg is 
Node , but the dynamic types of these objects in an execution may be any subtype of 
Node . Note, however, that judgement (6) is independent of the dynamic types of these 
objects. Indeed, having established judgement (6) means that the method works in every 
execution. This is because the logic is sound, as is shown in the next section. 
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5 Soundness 

This section states a soundness theorem, which proves the correctness of the operational 
semantics with respect to the axiomatic semantics. I first motivate the soundness the- 
orem, and then state it together with an informal explanation. The appendix provides 
some additional formal definitions and gives the proof. 

As a gentle step in presenting the full soundness theorem, consider the following 
theorem. 

Theorem 0. If one can derive both E, 0 h a : Object -> Boolean : f = true and 
nil, oq, 0, 0 h a ~> r, a, \x , then r = true . 

Here and in the next two theorems, cr 0 denotes a data store that satisfies 

(V& e H :: select(a Q , h, alloc) = false ) 

The theorem says that if in an environment E one can prove that a command a satisfies 
the transition relation f = true , then any terminating execution of command a from a 
"reset" state ends with a register value of true . 

A simple theorem about the result type of a command is the following. 

Theorem 1. If one can derive E, 0 ha : Object -> T : R and E \- ohj T and 
nil, (T 0 , 0, 0 h a ~> r,a, /x , then the value r has type T , that is, either r = nil or 
£h /x(r)(type) <: T. 

This theorem says that if one can prove, using the axiomatic semantics, that a command 
a has final type T , where T is an object type, and one can show that, operationally, the 
program terminates with a register value of r , then r is a value of type T (that is, it is 
nil or its allocated type is a subtype of T). This theorem shows the soundness of the 
type system's treatment of object types. 

An interesting theorem that says something about the final object store of a program 
is the following. 

Theorem 2. If one can derive both E, 0 h a : Object -> T : R and nil, er 0 , 0, 0 I - 
a ~> r,a, /x , then R[r, a ,f,a := nil, er 0 , r, a] holds as a first-order predicate. 

This theorem says that if one can prove the two judgements about a , then relation R 
actually describes the relation between the initial and final states. 

To prove the theorems above, one needs to prove something stronger. I call the 
stronger theorem, of which the theorems above are corollaries, the main theorem. The 
theorem is stated as follows. 
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Main Theorem. 



If 



(7) 

(8) 

(9) 

(10) 

(11) 



E,Vha:T ^ U :R 

r, cr, /x, S h a ~> r 1 , a' , fi' 

E, a, \x lh r : T 

E lh a, ix 

E, V, cr, n lh S 



and 
and 
and 
and 



then 



(12) 
(13) 
(14) 
(15) 



r, a, ^,or',5 \\-R 
(cr, /a) r< (a', /x') 
E,a',fi' lh r 7 : [/ 
£ lh o-',/x' 



, and 
, and 
, and 



In the antecedent of this theorem, (7) and (8) express the judgements that have been 
derived for some command a . One can hope to say something interesting in the con- 
clusion of the theorem only if the execution under consideration is from a "reasonable" 
state (r, cr, /x) and uses a "reasonable" stack S . Therefore, judgement (9) states that r 
is a value of type T, judgement (10) says that store pair (cr, /x) matches the environment 
E , and judgement (11) says that S is a well-typed stack. 

In the conclusion of the theorem, (12) expresses that R does indeed describe the 
relation between the initial and final states of the execution, and (14) expresses that r 1 
has type U . In addition, to use the theorem as a sufficiently strong induction hypothesis 
in the proof, (13) says that (cr, /x) is continued by (cr', /x') . This property expresses a 
kind of monotonicity that holds between two store pairs, the first of which precedes the 
other in some execution. Also, judgement (15) says that (cr', /x') , like the initial store 
pair, matches the environment. 

By removing (12) from the conclusion of the main theorem, one gets a corollary that 
expresses that the type system is sound with respect to the operational semantics. Such 
a corollary follows directly from the main theorem, but could also be proved directly in 
the same way that I prove the main theorem in the appendix. 

6 Limitations of the logic 

In this section, I discuss some limitations of the logic. 

The object construction command is rather awkward. Because it lists method imple- 
mentations, a method cannot directly construct objects whose type and method imple- 
mentations are the same as for self. Instead, one can declare object types representing 
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classes, as is done, for example, by Abadi and Cardelli [0]. As an example, consider 
an object type Seq representing sequences of elements as a linked list. If Seq has a 
method extend that creates a new node and appends it to the end of the linked list, then 
one cannot write: 

[Seq: 

extend = with self: Seq do . . . [Seq: . . . ] ... 

] , 

because the inner object construction command must textually contain whatever the 
outer one does. Rather, what works is to introduce an object type SeqClass with a 
method new that returns a new instance of type Seq , and to add a field class to Seq . 
One can then write: 

[SeqClass: new = with selfclass: SeqClass do 
[Seq: class = nil, 

extend = with self: Seq do . . . seZ/.class.new . . . 
]. class := selfclass 

].new 

One can consider modifying the present logic to remove the limitation from the ob- 
ject construction command. For example, like in common class-based object-oriented 
languages, one can extend the program environment to include method implementa- 
tions. One must then have a "link-time" check that ensures that every method that 
may be called by the program at run-time has an implementation. Or, like in common 
object-based languages, one can add a construct for cloning objects or their method 
implementations. 

Another omission from the present logic is the ability to compare objects for equal- 
ity. Just like one would expect to add primitive types like integers to the present logic, 
one would expect to add more general expressions, including comparison expressions. 
(It is actually possible, though quite cumbersome, to encode a mechanism by which the 
present logic can test whether or not a field is nil : Introduce a boolean field f IsNil for 
each object- valued field f , and then program so as to maintain the condition 

(f = nil =>• flsNil = true) A (f ^ nil =>• flsNil = false) 

as an invariant of every object.) 

A logic of programs provides a connection between programs and their specifica- 
tions. In the present logic, method declarations contain specifications that are given 
simply as transition relations. Transition relations are not practically suited for writing 
down method specifications, because they are painfully explicit. Specification features 
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like modifies clauses and abstract fields would remedy the situation, but lie outside the 
scope of this paper. To mention some work in this area, Lano and Haughton [9] have 
surveyed object-oriented specifications, and my thesis [11] shows how to deal with mod- 
ifies clauses and data abstraction in modular, object-oriented programs. The logic for 
POOL [3] includes some specification features that can be used to state properties of 
recursive data structures. 

7 Summary 

I have presented a sound logic for object-oriented programs whose commands are im- 
perative and whose objects are references to data fields. The programming notation 
requires that types, fields, and methods be declared in the environment before they can 
be used in a program. The main contributions of the paper are the logic itself, the sound- 
ness theorem, and the way that types are handled, which makes the subtype relation and 
the admission of recursive object types trivial. 
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A Proof of the main soundness theorem 
A.O Definitions 

This subsection gives the definitions of the judgements used in the soundness theorem. 

Definition of holds. Judgement r, a, r J , a', S lh R says that R is a relation that, 
when interpreted using r, a , r 1 , a' , and 5, is a provable first-order formula. The 
judgement is defined as \-f ot R[r, a ,r,a := r, a, r 1 , cr'][S] , where [S] denotes the fol- 
lowing substitution: for every v e dom(S) , every free occurrence of variable v is 
replaced by the result of the function application S(v) . I assume throughout that the 
domain of S does not contain values from V, U {false, true, nil} (which I will denote h , 
c , or r, possibly primed), field names (like f or alloc), nor data stores (which I will 
denote a , possibly primed). 

For example, to derive r, a, r' , a' , S lh selectia , r, f ) = v, where v e dom(S) , 
one must establish hy c / selectia' , r, f) = x, where S(v) = x (I will often write simply 
\-f 0 i select(a' , r, f) = 5(v) ). Here, I assumed that none of a' , r , or f is in the domain 
of S. 

Definition of < . A store pair ia, /x) is said to be continued by a store pair 
ia', ix') , written ia, /x) < ia', /x') , when 

CO for every h e V, , selectia, h, alloc) = true =^ selectia' , h, alloc) = true , and 
CI fi < fi' 

Condition CO says that any object allocated in a remains allocated in a' , and CI says 
that /x' contains the same type information and method implementations as /x does 
for those objects in Jom(/x) , but /x' may also contain information about objects not in 
domiix) . 

Note that < is reflexive and transitive. 

Definition of has-type. For any environment E , store pair ia, /x) , value r , and 
type T , the judgement 

E, a, \x lh r : T 

says that T is a type in E and that r is allocated and has type T in ia, /x) . The 
judgement is derived using the following rules: 

E h" const C. T 

E, a, ix lh c : T 
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E \- ob j T select(a, r, alloc) = true /x(r) (type) = T 
HI 

E, cr, /x lh r : T 

E,a,n\\-r:U E h U <: T 
H2 

E, a, ix lh r : T 

Note that the judgement E, cr, /x I h r : T is monotonic in (er, /x) with respect to the 
< ordering: from E,a, jx lh r : T and (cr, /x) ;< (cr', /x') , it follows that E,a', /x' lh 
r : T . The judgement is also monotonic in T with respect to the <: ordering: from 
E, a, /x lh r : T and £ h T <: U , it follows that E, a, /x lh r : U . 

Observe that any derivation of E, a, /x lh r : T consists of exactly one application 
of HO or HI, followed by some number of applications of H2. For any object type T , 
rule HI (not HO) is applied when reH, since V, does not contain nil . We arrive at 
the following lemma, which will show to be useful in the proof: 

Lemma about has-type. If E h 0 y T , E, cr, fi lh r : T , and r e K , then 
select(cr, r, alloc) = true and E h /x(r)(type) <: 7\ 



Definition of matching. For any environment £ and store pair (cr, /x) , the judge- 
ment E lh cr, /x says that (cr, /x) matches environment £\ The matching judgement 
holds when all of the following hold: 

MO for every h e V, , select(o, h, alloc) = ?rw<? = /ie dom(fi) 
Ml for every /z e dom(ji) , /x(/z)(type) is defined 

M2 for all /* , f , T , U , such that h e % , select(a, h, alloc) = true , and f : T -> t/ e 
Fields(ix(h)(type),E) , 

E,a, [M lh select (a, h,\) : U 

M3 for all /z , m , T , £/ , 7? , such that h eH, select(a, h, alloc) = zrwe , and m: T -> 
t/ : e Methods([i(h)(\.ype),E) , 

£,0h/x(/i)(m):r^[/:/? 

Rule MO states that the objects allocated in cr are the objects about which /x contains 
information, and Ml states that /x contains type information for each of those objects. 
Rule M2 says that every declared field of an allocated object has the appropriate type. 
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Rule M3 says that every declared method of an allocated object has an implementation 
in /x that satisfies the declared method specification. 

Definition of well-typed stack. The definition of a well-typed stack uses a func- 
tion ids. For V a list of local variable declarations (like v:T), ids(V) denotes the set 
of identifiers (that is, v ) of those declarations. 

For any environment (E, V) , store pair (a, /x) , and stack S , the judgement E, V, 
a, jxW S says that S is well-typed with respect to V . The judgement holds when 

50 dom(S) = ids(V) , and 

51 E, a, /x lh S(v) : T holds for every v: T pair in V . 

Note that, because has-type is monotonic in (er, /x) , so is the well-typed stack judge- 
ment. 

A.l Proof 

This subsection gives the proof of the main soundness theorem. The proof is by in- 
duction on the lexicographic pair (d, e) , where d is the derivation of the operational- 
semantics judgement about command a , and e is the axiomatic-semantics derivation 
of the judgement about a . The proof is a case study of the last rule applied in derivation 
e . 

Subsumption. We're given 

E, V h a : T 0 -> T 3 : R' r, a, /x, S h a ~> r 1 , a', /x' 
E, a, ix lh r : T 0 E\\ra,ix E,V,a,ix\VS 

Since this case considers subsumption, we are given that the first of these formulas has 
been derived from 

E, V h a : T { -> T 2 : R 

EhT 0 <:T { EhT 2 <: T 3 h fol R R' E,V h rel R' . 

We attempt to invoke the induction hypothesis with T, U, R:=T\, T 2 , R . To do so, we 
must first establish 

E, o, ix I h r : T\ , 

which follows from E, a, fx lh r : Tq , E h To <: T\ , and the monotonicity of has-type. 
By the induction hypothesis, we then have 

r,a,r",a',S\^ R (a, fx) < (a', fx') E, a' , /x' lh r 1 : T 2 E\^a',fx'. 
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Now for our proof obligations: 

• r, cr, r* , cr', S lh R' . Follows from r, cr, r* , a' , S lh R, \-f ot R R' , and the 
monotonicity of holds. 

• (c> AO ^ M-0 • Follows directly from induction hypothesis. 

• £, cr', [xl lh / : T 3 . Follows from £, cr', /x' lh / : T 2 , E h T 2 <: T 3 , and the 
monotonicity of has-type. 

• £ lh cr', // . Follows directly from induction hypothesis. 

Constant. In this case and all remaining cases, the axiomatic semantics rule consid- 
ered in the case determines the shape of the command, which in turn determines which 
kind of operational semantics rule has been applied. 
We're given 

E,V\-c:U—*T:r = cAo=6 r, a, /x, S h c ~> c, a, \x 
E,cr, jx lh r : U E lh cr, /x E, V , cr, /x I h 5 

derived from 

£,Vho £ h co „ if c: T E £/ 

We prove: 

• r, cr, c, cr, 5 lh f = c A o = 6 
= { definition of holds } 

\-foi (r = c A a = a)[r,a, r, a := r, cr, c, a][S] 
= { substitution } 

\-foi c = c A a = a 

which is a tautology. 

• (c> AO ^ (c, A 1 ) • ^ is reflexive. 

• E, cr, /x lh c : T . Follows from E \- const c: T and HO of the definition of has-type. 

• E lh cr, jju . Given. 



25 



Local variable. We're given 

E, V\-v:U—*T: r = vAcr=6 r, a, /x, S h v ~> r' , a, \x 
E, a, fx \\~ r : U E lh a, fi E,V, a, fx lh S 

where the axiomatic-semantics judgement has been derived from 

E, V h var v:T E U 
and the operational- semantics judgement has been derived from 

r' = S(v) 
We prove: 

• r, o, r 1 , a, S lh r = v A a = a 
= { definition of holds } 

l-/ 0 / (r = v A a = &)[r, a, f, a := r, a, r 1 , a][S] 
= { substitution } 

\- f oi r 1 = S(v) A a = a 

which follows from r' = S(v) . 

• (c> AO ^ (c> £0 • ^ is reflexive. 

• E, a, fx \\~ r 1 : T . Follows from r 1 = S(v) , E, V \- var v: 7 1 , and the definition of 
E, V,a, ix lh S. 

• E lh a, ix . Given. 

Conditional. There are two subcases, because the operational- semantics judgement 
can be derived from one of two rules. I show the proof for the false -rule; the true -rule 
is similar. We're given 

£,Vhco<>fli : Boolean — > T : (r = false =>• Rq) a (r = true =>• Ri) 
false, a, ix, S \- a 0 oai^Z, a', fx' 

E, a, ix lh false : Boolean E\\-a,fx E,V,a,ix\VS , 
derived from 

E, V h ao : Boolean T : Rq E, V h ai : Boolean T : Ri 
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false, a, /x, S h ao ~> r, cr', /x' 

By the induction hypothesis applied on a 0 , we have: 

false, a, r 1 , a', S lh i?o (c> M-) ^ AO 
E,o',n' lh r' : r £ lh a', /z' 

We prove: 

• false, a, r 1 , a' , S \\~ (r = false =>• i?o) A (r = true =>• 
= { definition of holds } 

\~foi (0" = false =>• i?o) A (r = true =>• Ri)) 
[r, cr ,f,cr := false, o, f ', cr'][S] 
= { substitution } 

\-foi (false = false =>• Ro[r, cr, r, 6 := false, o, r 1 , cr'] [S]) A 

(false = true =>• Ri[r, cr , r, cr := false, a, r* , cr'][S]) 
= { propositional calculus, using axiom (1): false ^ true } 

\~foi RqV", cr,r,e := false, a, r 1 , er'HS] 
= { definition of holds } 

false, a, r 1 , cr' , S lh Rq , 

which comes directly from the induction hypothesis. 

• (cr, ii) < (cr', fx') . Directly from induction hypothesis. 

• E, a', fx' lh r 1 : T . Directly from induction hypothesis. 

• E lh a', fx' . Directly from induction hypothesis. 

Composition. We're given 

E,V V- <3 0 ; «i : To — > T 2 : (3r, a :: Ro[r, a := r, a] A Ri[r, a := r, a] } 

r, cr, ix, S \~ ao ', a\ ~> r" , a" , \x" 

E, a, (x lh r : To E lh a, \x E,V,a, \x lh S , 

derived from 

E,V\- a Q : T 0 -> T x : R 0 E,Vha l :T l ^T 2 :R l 
f and a do not occur free in R 0 or Ri 
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and 

r, a, fi, S \- ao ^ r' , a' , /x' /, a' , /x', S \- ai ^ r", a" , /x" 

Applying the induction hypothesis on a 0 , we get: 

r, a, r',a', S lh tf 0 (a, fi) < (a', fi') 
E,o',y! lh r 7 : T i E\Yo',y! 

We wish to invoke the induction hypothesis also on a\ . This requires that we first 
establish 

E,o',ii' lh r' : T x EWo'^ E,V,a' ', fi' lh 5 

The first two of these judgements come directly from the application of the induction 
hypothesis on a 0 ; the third follows from E, V,cr, fi lh S , (a, /x) < (a', /x') , and the 
monotonicity of well-typed stacks. By the induction hypothesis applied to a\ , we now 
have: 

r J , a', r", a", S lh R Y (a', /x') < (a", ft") 
E,a",fx" lh r" :T 2 E\Ya",fx" 

Now for the proof obligations: 

• r, a, r", a" , S lh (3r, a :: Ro[r, a := f, a] A i?i[r, a := r, a] } 
= { definition of holds } 

y o/ (3r, a :: i? 0 [r, a := r, a] A ^[r, a := r, a] ) 
[r.ff.r.a :=r,a,r",a"][5] 
•<= { instantiate f, a := r J , a' , since substitution is monotonic } 

h>/ (/? 0 [r, 6 := r, a] A Rdr, a := r, a])[f, a := r\ a'] 
[r,a, f, 6 := r, a, r" , cr"][S] 
= { substitution, since R 0 and R\ are free of f and a } 

hyw i? 0 [r, a, f, a := r, a, r', A ^[r, a, f, a := r', a', r", a"][S] 

= { satisfiability distributes over A } 

\-f 0 i Ro[r,a, f, a := r, a, r 7 , a'] [5] 
hyw Mr, <7,r,<r :=r / ,or',r",a"][S] 
= { definition of holds, twice } 

r, a, r J ,o',S\V R 0 
r',a',r",a",S\VR x 

which come directly from the induction hypotheses. 
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• O', fi') < O", fi") • Follows from (a, /x) ^ (a', /x') and (a', /x') ^ (a", /x") , 
and transitivity of < . 

• E, a", /x" lh r" : T 2 . Follows directly from the induction hypothesis applied to 
a\ . 

• E lh a", ix" . Follows directly from the induction hypothesis applied to a\ . 

Binding. We're given 

E, V h with v.T doa:T -> U :R[v:=r] 
r, a, [M,S h wzY/z v: T do a r 1 , a' , \x' 
E,a,ix\Vr:T £ lh er, /x E,V, a, /x lh 5 

derived from 

£, (V, v: T) h a : r -> C/ : 7? 

and 

r, er, /x, S.(v i-> r) h a ~> r', a' , \x 

We'd like to apply the induction hypothesis on command a , transition relation R , com- 
mand environment (E, (V, v: T)) , and stack S.(y i-> r) . In order to do so, we must first 
establish 

E, (V,v:T),a,ix lhS.(vi-> r) 

which follows from E, V,a, /x lh S , E, er, /x lh (S.(v i-> r))(v) : T , and the definition 
of well-typed stacks, since (S.(v h-> r))(v) = r and we're given E,a,fx lh r : 7. 
Invoking the induction hypothesis as planned, we obtain: 

r, a, r', a', S.(v ^ r) lh 7? (a, /x) ^ (a', /x') 
£,o-',/x' lh r 7 : U E\Yo',ix' 

Now: 

• r,a,r",a',S\Y R[v:=r] 

= { definition of holds } 

h M R[v := r][r,cr, f, 6 := r, a, r 1 , a'][S] 
= { v does not occur free in R[v := r][r, a, f, a := r, a, r 7 , a'] , the 

argument to [5] } 



29 

\- f oi R[v := r][r, a, f, 6 := r, a, r\ a'][S.(v h> r)] 
•<= { substitution is weakening and monotonic } 

\-foi R[r, o ,r,6 := r, o, r 1 , cr'][5.(v h-> r)] 
= { definition of holds } 

r,a, r",a',S.(v\-> r) \VR 

which comes directly from the induction hypothesis. 

• (cr, ^) < (a', ^') . Directly from induction hypothesis. 

• E, a', lh r 1 : U . Directly from induction hypothesis. 

• E lh a', ii' . Directly from induction hypothesis. 

Object construction. We're given 

E, V h [T: h = Ci m, = a^ J \ : U -> T : 

f ^ nil A select(o , f, alloc) = false A 

6 = store(- ■ ■ (store (a , f, alloc, true), f, f,, q) ,6/ 
r, o, fx, S h [T: f, = a ieI , m, = Oj jeJ ] ~> a', /x' 
E,o,ix\Yr:U E\Yo,ix E,V, a, /x lh 5 

derived from 

£,Vr-o £ h^ e [/ £ h oy T 

f ; -: Ti -> Ui ,6/ are the elements of Fields (T, E) 

m, : Tj ^ Uj : Rj jeJ are the elements of Methods (T, E) 

E h const Ci : Ui ieI E,0h aj :T^ Uj: Rj & 

and 

h gV, select(o, h, alloc) = false 

a' = store(- ■ ■ (store(cr, h, alloc, true), h, f,-, c,) ,6/ 

/i' = j(i.(/!h> (type h» r, m, h» aj jeJ )) 

We prove: 

• r, a, h, a' , S lh f 7^ ni7 A select(a, f, alloc) = false A 

6 = store(- ■ ■ (store (a , f, alloc, true), f, f,, c,) ,6/ 
= { definition of holds } 
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\~foi ix # nil A selectip , f, alloc) = false A 

6 = store(- ■ ■ (store (a , f, alloc, true), f, f,, c ; ) ,e/ ) 
[r, a ,f,a := r, a, h, a'][S] 
= { substitution } 

\~foi h ^ nil A select(o, h, alloc) = false A 

a' = store(- ■■ (store(a, h, alloc, true), h,ii,Ci) ieI 

which follows directly from nil g V, and the way the hypothesis is derived. 

• (&, /-O ^ (o - ', M-0 • Re CO: For any k e V, , select(a, k, alloc) differs from 
selectip' , k, alloc) only for k = h , and we're given select(cr, h, alloc) = false . 
Re CI: To prove \x < jx' , it suffices to show h g dom(fx) , which follows from 
selectip, h, alloc) = false and MO in the definition of the given judgement E Ih 
o, fx . 

• E,o' , ix' lh h : T . Follows from the facts E \- oh j T , select(cr', h, alloc) = true , 
ix'(h) (type) = T , and HI in the definition of has-type. 

• E lh a' , fx' . Follows from E lh o, fx and the following observations. Re MO: 
We have selectip', h, alloc) = true and /z e dom(ix') . Re Ml: /x'(/z)(type) is 
defined. Re M2: For each appropriate f, , we have selectip' , h, f,) = c, , so we 
need to show E, a' , fx' lh c,- : [/,■ , which follows from HO and £ h- co „ sf c,-: £/,■ . 
Re M3: For each appropriate m, , we have ix'(h)(V(\) = Oj, and we're given 
E, 0 h a) : : r -> L5 : : ^ • 

Field selection. We're given 

E, V h f : T —> U : r y£ nil =>• f = select(cr , r, f ) A a = a 
r, a, ix, S h f ~> / , cr, \x 

E, a, fx \\~ r : T E\\~a,fx E,V, a, fx lh S 
derived from 

E,Vho E h field \:T^U 



r G K r 1 = select(a, r, f) 

Now: 
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• r, cr, r 1 , cr, S lh r nil =>• r = select(cr, r, f) A cr = a 
= { definition of holds } 

\~foi 0" # nil =>• r = select(cr, r, f) A a = cr)[r, cr ,f,a := r, a, r 1 , cr][S] 
= { substitution } 

\-f 0 i r ^ nil =>• r 1 = select(a, r, f) A a = a , 

which holds because r e V, , nil ^H, and r 1 = select(cr, r, f) . 

• (c> AO ^ (c> AO • ^ is reflexive. 

• E,a,fx lh r 7 : t/. From the way E \-fi e i d t:T -> U was derived, we have 
E \- 0 bj T . Thus, from E, cr, [/, \\- r : T , r e T-L , and the lemma about has-type, we 
have select(<7, r, alloc) = true and E h /x(r)(type) <: 7\ Thus by M2 in the 
definition of the given E lh cr, /x , we have E,a, fi lh select(cr, r, f) : [/ . Since 
/ = select(cr, r, f) , the proof obligation follows. 

• £ lh cr, [i . Given. 

Field update. We're given 

E, V h f := v : 7\ — > 5"i : r 7^ ni7 =>• r = f A a = store(cr, r, f, v) 
r, a, /x, 5 h f := v ~> r, a' , /x 

E, a, fi. \\~ r : T\ E lh cr, /x £, V, cr, /x lh S , 
derived from 

£ \-fieu f: r 0 -> C/ 0 E h 7i <: 7 0 
£,^ m v:[/, £h[/K:[/ 0 

and 

r £ K cr' = store(cr, r, f, 5(v)) 

Now: 

• r, cr, r, 0' , S \\~ r ^ nil =>• r = f A cr = store (a , r, f, v) 
= { definition of holds } 

h>/ (r ^ nil =>• r = f A a = store (a , r, f, v))[r, cr ,f,a := r, a, r, cr'][S] 
= { substitution } 

hy 0 / r ^ nil =>• r = r A cr' = store(cr, r, f, 5(v)) , 

which follows from the way the hypothesis is derived. 
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• (c> M<) ^ (cr', jit,) . Follows from the fact that, for all /z, select(a, h, alloc) = 
select(cr', h, alloc) . 

• £, cr', /x lh r : Ti . Follows from E,o, n \V r : T\, (cr, /x) < (cr', /x) , and the 
monotonicity of has-type. 

• E \\- <r', fjL. Because of E lh cr, /x and the observation above that no alloc field 
has changed between a and o' , it suffices to show E, cr', /x lh select(a',f, f) : 
Uq , which we do by the following calculation that starts from two givens: 

E,V,o,il\\-S E,Vh var v:U { 
=>• { definition of well-typed stack } 

E,a,fi IhS(v) : U x 
=> { EhU { <: U 0 andH2 } 

E,a,fi lh S(v) : C/ 0 
=>■ { (cr, jii) ^ (cr', jii) and monotonicity of has-type } 

£,cr',/x lh 5(v) : C/ 0 
= { select I store axiom (0) } 

E, cr', (i lh select (store (a, r, f, S(v)), r, f) : Uq 
= { cr' = store(a, r, f, S(v)) } 

E, a' , /x lh select{o\ r, f) : Uq 

Method invocation. We're given 

E, V h m : T -> U : r ^ nil =>• r,a,/i,5hm^/,ff>' 
£, a, /x lh r : T £ lh a, /x £, V , cr, /x I h S 

derived from 

E,Vho E ^method m: T ^ U : R 

and 

r £ K a = /x(r)(m) r, cr, /x, 0 h a ~> r', cr', /x' 

We wish to apply the induction hypothesis on command a , relation R , and with V, S := 
0,0. This requires that we first establish E,0,cr, jx lh 0 , which holds trivially, and 
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E,0ha:T^ U:R 
■$= { a = /x(r)(m) , and M3 of E Ih a, fi } 

select(cr, r, alloc) = true r e V, 

m: T -> [/ : i? e Methods (/x(r) (type), £) , 
•<= { £ l-mef/iod m: r -> t/ : R and definition of Methods } 

select(cr, r, alloc) = true r G V, 

E h /x(r)(type) <: T 
•<= { lemma about has-type } 

E, er, n Ih r : T E h 0 y T r e W. 

The first of these is given, the second follows from the way E \- met hod m: T —> U : R is 
derived, and the third follows from the way the given operational- semantics judgement 
is derived. 

We now apply the induction hypothesis as planned, and get: 

r,a,r',a',0 Ih (a, /x) < (V, /x') E, a', fj,' Ih r 1 : U E\Va\[i! . 

Now for the proof obligations: 

• r, a, r 1 , a' , S \\~ r ^ nil =>• R 
= { definition of holds } 

\- fo iir^nil R)[r, a, f, 6 := r, a, r 1 , a'][S] 
•<= { substitution is monotonic } 

\- f oi R[r,cr, f, a :=r,a,r J , cr'][S] 
•<= { the substitution function [S] is monotonic in the domain of S } 

\- fot R[r,cr, f, 6 :=r,o,r J , cr'][0] 
= { definition of holds } 

r,ory,or',0 \\~R 

which comes directly from the induction hypothesis. 

• (c> £0 ^ M-0 • Directly from induction hypothesis. 

• E, a' , n' \\- r 1 : U . Directly from induction hypothesis. 

• E\Y o' ,y! . Directly from induction hypothesis. 
And that completes all cases of the proof. 



34 



References 

[0] Martin Abadi and Luca Cardelli. A Theory of Objects. Springer- Verlag, 1996. 

[1] Martin Abadi and K. Rustan M. Leino. A logic of object-oriented programs. 
In Theory and Practice of Software Development: Proceedings / TAPSOFT '97, 
7th International Joint Conference CAAP/FASE, volume 1214 of Lecture Notes in 
Computer Science, pages 682-696. Springer, April 1997. 

[2] Roberto M. Amadio and Luca Cardelli. Subtyping recursive types. ACM Transac- 
tions on Programming Languages and Systems, 15(4):575-631, September 1993. 

[3] Pierre America and Frank de Boer. Reasoning about dynamically evolving process 
structures. Formal Aspects of Computing, 6(3):269-316, 1994. 

[4] Craig Chambers. The Cecil language: Specification & rationale, version 2.1, 
March 7, 1997. Available from http :/ /www . cs . Washington . edu/re 
search /projects/ cecil/ www/Papers/ cecil-spec . html, 1997. 

[5] Krishna Kishore Dhara and Gary T. Leavens. Forcing behavioral subtyping 
through specification inheritance. Technical Report TR #95-20c, Iowa State Uni- 
versity, Department of Computer Science, 1997. 

[6] Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, Englewood 
Cliffs, NJ, 1976. 

[7] James Gosling, Bill Joy, and Guy Steele. The Java™ Language Specification. 
Addison- Wesley, 1996. 

[8] C. A. R. Hoare. An axiomatic basis for computer programming. Communications 
of the ACM, 12(10):576-580,583, October 1969. 

[9] Kevin Lano and Howard Haughton. Object-Oriented Specification Case Studies. 
Prentice Hall, New York, 1994. 

[10] Gary Todd Leavens. Verifying Object-Oriented Programs that Use Subtypes. PhD 
thesis, MIT Laboratory for Computer Science, February 1989. Available as Tech- 
nical Report MIT/LCS/TR-439. 

[11] K. Rustan M. Leino. Toward Reliable Modular Programs. PhD thesis, California 
Institute of Technology, January 1995. Available as Technical Report Caltech-CS- 
TR-95-03. 



35 



[12] K. Rustan M. Leino. Ecstatic: An object-oriented programming language with 
an axiomatic semantics. In The Fourth International Workshop on Founda- 
tions of Object-Oriented Languages, January 1997. Proceedings available from 

http : / / www . cs . indiana . edu/ hyp lan /pierce/ f ool/ . 

[13] K. Rustan M. Leino and Greg Nelson. Object-oriented guarded commands. In- 
ternal manuscript KRML 50, Digital Equipment Corporation Systems Research 
Center, March 1995. 

[14] Greg Nelson. Verifying reachability invariants of linked structures. Conference 
Record of the Tenth Annual ACM Symposium on Principles of Programming Lan- 
guages, pages 38-47, January 1983. 

[15] Greg Nelson, editor. Systems Programming with Modula-3. Series in Innovative 
Technology. Prentice-Hall, Englewood Cliffs, NJ, 1991. 

[16] Arnd Poetzsch-Heffter and Peter Muller. A logic for the verification of object- 
oriented programs. In R. Berghammer and F. Simon, editors, Programming Lan- 
guages and Fundamentals of Programming. Christian Albrechts-Universitat Kiel, 
1997. Available from http : //voss . f ernuni-hagen . de/pi5/f orsch 
ung/ veroef f ent lichungen/uebersicht_en . html. 



